home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SGI Freeware 2001 May
/
SGI Freeware 2001 May - Disc 1.iso
/
dist
/
fw_hylafax.idb
/
usr
/
freeware
/
man
/
cat4
/
hylafax.Z
/
hylafax
Wrap
Text File
|
2000-06-09
|
32KB
|
595 lines
HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((JJJJaaaannnnuuuuaaaarrrryyyy 11118888,,,, 1111999999996666)))) HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF))))
NNNNAAAAMMMMEEEE
HylaFAX - introduction to _H_y_l_a_F_A_X server operation and file
formats
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
_H_y_l_a_F_A_X is a system for sending and receiving facsimile. It
supports queued transmission and asynchronous reception of
facsimile. Ancillary programs are invoked by the system for
flexibility and configurability. _H_y_l_a_F_A_X includes client
and server programs to support remote submission of jobs for
transmission, remote removal of queued jobs, and to remotely
query the status of jobs queued for transmission. This
document describes the organization of the filesystem
spooling area in which _H_y_l_a_F_A_X server and server-related
processes operate, and introduces the various files that
reside in the spooling area.
OOOOVVVVEEEERRRRVVVVIIIIEEEEWWWW
The spooling area is typically located under the directory
/_u_s_r/_f_r_e_e_w_a_r_e/_v_a_r/_s_p_o_o_l/_f_a_x. Ancillary command scripts used
by the server programs _f_a_x_q(1M), _f_a_x_s_e_n_d(1M), _p_a_g_e_s_e_n_d(1M),
and _f_a_x_g_e_t_t_y(1M) are located in the bbbbiiiinnnn subdirectory.
Configuration, access control, and accounting information
are maintained in the eeeettttcccc and ccccoooonnnnffffiiiigggg subdirectories.
Outgoing jobs are described by files in the sssseeeennnnddddqqqq
subdirectory, while received facsimile are deposited in the
rrrreeeeccccvvvvqqqq subdirectory. The ddddooooccccqqqq and tttteeeemmmmpppp subdirectories are
also used in the preparation of outbound jobs; the latter
holds files that may be freely purged while the former holds
client files that may reside on the server independent of an
associated job. The ddddoooonnnneeeeqqqq subdirectory holds jobs that have
completed but have not yet been purged or archived. On
systems with job archival support, completed jobs that have
been archived are placed in the aaaarrrrcccchhhhiiiivvvveeee subdirectory. The
ppppoooollllllllqqqq subdirectory holds documents that are available for
polled retrieval from the server. The iiiinnnnffffoooo subdirectory
contains files that describe the capabilities of facsimile
machines that _H_y_l_a_F_A_X has called-this information is used in
preparing documents for transmission. The ssssttttaaaattttuuuussss
subdirectory contains files that server processes write
their current status to. The lllloooogggg subdirectory contains
logging information about send and receive sessions. The
cccclllliiiieeeennnntttt subdirectory contains FIFO special files used for
communication with _f_a_x_q.
_H_y_l_a_F_A_X supports multiple modems on a host. A single
process acts as central queueing agent for all outbound
jobs. Typically each modem also has a server process that
monitors the modem status and handles inbound phone calls.
Per-modem server processes communicate with the central
queueing agent using FIFO special files; see _m_k_n_o_d(2) or
_m_k_f_i_f_o(2). Any other synchronization between server
Page 1 (printed 3/21/00)
HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((JJJJaaaannnnuuuuaaaarrrryyyy 11118888,,,, 1111999999996666)))) HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF))))
processes is done using file-level locking. The _f_a_x_q
process listens for commands written to the file named FFFFIIIIFFFFOOOO,
while each _f_a_x_g_e_t_t_y process listens for commands written to
a per-device file named FFFFIIIIFFFFOOOO._d_e_v_i_d (where _d_e_v_i_d is an
identifier derived from the name of the device special file
to which the modem is connected; e.g. _t_t_y_m_2 for /_d_e_v/_t_t_y_m_2,
_t_e_r_m__1_0 for /_d_e_v/_t_e_r_m/_1_0.) To send a command to the
queueing agent, one writes to FFFFIIIIFFFFOOOO. This is useful, for
example, for submitting a job for transmission. To send a
command to a specific _f_a_x_g_e_t_t_y process, the FFFFIIIIFFFFOOOO._d_e_v_i_d file
is used.
Client applications interact with a _H_y_l_a_F_A_X server machine
using a communications protocol implemented by the _h_f_a_x_d(1M)
program. The _h_f_a_x_d program is typically started at system
startup; it listens for client requests for service and
creates a process for each client. _h_f_a_x_d supports the
submission of outbound jobs, querying the status of the send
and receive queues, and altering parameters of previously
submitted jobs. The _h_f_a_x_d processes communicate with the
_f_a_x_q process through FIFO special files. Commands sent to
_f_a_x_q are sent to FFFFIIIIFFFFOOOO and responses are received on FIFO
files that each _h_f_a_x_d creates in the cccclllliiiieeeennnntttt subdirectory.
SSSSEEEETTTTUUUUPPPP
Each _H_y_l_a_F_A_X server machine must run the _f_a_x_s_e_t_u_p(1M)
command prior to starting up _H_y_l_a_F_A_X server processes.
_f_a_x_s_e_t_u_p verifys that the _H_y_l_a_F_A_X software has been
installed correctly and that any parameters that were
specified at the time the software was built are appropriate
for the system.
SSSSEEEENNNNDDDDIIIINNNNGGGG
Each outgoing facsimile job has a job description file that
is located in the sssseeeennnnddddqqqq subdirectory. This file contains
all the information necessary to manage the transmission;
c.f. _s_e_n_d_q(4F). The actual documents that are to be sent
are usually located in the ddddooooccccqqqq subdirectory (though it is
also possible to reference documents from the rrrreeeeccccvvvvqqqq
directory). _H_y_l_a_F_A_X accepts POSTSCRIPT, PCL, and TIFF
documents for transmission (though support for PCL documents
is not currently implemented). Documents are automatically
converted to TIFF/F documents prior to transmission
according to the capabilities of the remote facsimile
machine: maximum page width and length, ability to handle
2D-encoded data, and ability to handle high resolution (7
line/mm) data. This remote machine capability information
is stored in files in the iiiinnnnffffoooo subdirectory. If a machine
has not been called before, _H_y_l_a_F_A_X assumes the remote
machine has the requested capabilities. If a capabilities
mismatch is detected while sending a facsimile _H_y_l_a_F_A_X will
disconnect and reconvert the submitted documents according
Page 2 (printed 3/21/00)
HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((JJJJaaaannnnuuuuaaaarrrryyyy 11118888,,,, 1111999999996666)))) HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF))))
to the newly discovered capabilities. Users may also
restrict the session parameters used to format documents on
a per-job basis.
The actual transmission is handled by a _f_a_x_s_e_n_d(1M) process
that is initiated by the scheduler. This program may be
substituted for by specifying the FFFFaaaaxxxxSSSSeeeennnnddddCCCCmmmmdddd configuration
parameter in the _f_a_x_q configuration file.
While a job is being processed by a server process, its job
description file is locked for exclusive use with _f_l_o_c_k(2).
The _h_f_a_x_d(1M) program uses this information to tell if a job
is actively being processed.
If the SSSSeeeessssssssiiiioooonnnnTTTTrrrraaaacccciiiinnnngggg parameter in a server's configuration
file is non-zero, then tracing information for an outgoing
job will be logged in a file in the lllloooogggg subdirectory. Each
destination machine has a separate log file named by its
canonical phone number.
The remote job submission facility includes host and user
access control. The file eeeettttcccc////hhhhoooossssttttssss must be present and list
those hosts and users that are permitted to queue jobs for
transmission or do other operations that alter the status of
a job. Note that it is necessary to include the ``local
host'' definition (usually 127.0.0.1) if local submission is
to be permitted. For more information consult _h_o_s_t_s(4F).
There are a number of controls on outbound calls that can be
specified using the eeeettttcccc////ddddeeeessssttttccccoooonnnnttttrrrroooollllssss file (or whatever file
is specified in a DDDDeeeessssttttCCCCoooonnnnttttrrrroooollllssss configuration parameter in
the _f_a_x_q configuration file). This file, described in
_d_e_s_t_c_t_r_l_s(4F), allows an administrator to restrict calls by
phone number and to control the time of day that calls may
be placed. In addition, operational parameters such as the
maximum number of pages in a facsimile transmission can be
constrained on a per-destination basis.
If an error is encountered during transmission and a
subsequent retransmission would not include the original
cover page, then _H_y_l_a_F_A_X can be configured to generate a
_c_o_n_t_i_n_u_a_t_i_o_n _c_o_v_e_r _p_a_g_e that is prepended to the
retransmitted pages. Such cover pages are usually generated
by the bbbbiiiinnnn////mmmmkkkkccccoooovvvveeeerrrr command; though the exact command to use
can be specified in the configuration file read by _f_a_x_q.
_H_y_l_a_F_A_X can be configured to generate a line of status
information across the top of each page of an outbound
facsimile. This information, termed a ``tagline'',
typically includes the sender's identity (i.e. phone
number), the time and date of the transmission, and the page
number. The exact format of the tagline is configurable and
Page 3 (printed 3/21/00)
HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((JJJJaaaannnnuuuuaaaarrrryyyy 11118888,,,, 1111999999996666)))) HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF))))
applications can override the default configuration
parameters on a per-job basis. Note that in the United
States the law requires that a tagline that identifies the
sender's phone number must appear on each transmitted page
of facsimile.
Facsimile transmitted to receivers that accept variable-
length pages may have short pages ``_c_h_o_p_p_e_d''. That is, if
a page has a significant amount of trailing whitespace and
the receiver accepts variable-length pages then only the top
part of the page will be transmitted. _f_a_x_q can be
configured so that only the last page of each document is
potentially chopped, all pages are potentially chopped, or
chopping is disabled. The minimum whitespace threshold is
also configurable. Applications can override the default
configuration parameters on a per-job basis.
RRRREEEECCCCEEEEIIIIVVVVIIIINNNNGGGG
_f_a_x_g_e_t_t_y server processes can be configured to answer
incoming phone calls and automatically receive facsimile.
Received documents are placed in the rrrreeeeccccvvvvqqqq subdirectory as
TIFF Class F files. The _f_a_x_g_e_t_t_y processes can be
configured to make these files publicly accessible, or they
can be made private in which case an administrator must
manage their delivery and/or the assignment of ownership to
particular users. When a facsimile is received, the
_f_a_x_g_e_t_t_y process usually invokes the bbbbiiiinnnn////ffffaaaaxxxxrrrrccccvvvvdddd command;
though the exact command to invoke can be specified in the
per-modem configuration file. The default _n_o_t_i_f_y command is
a shell script that sends a mail message to a well known
user, the _F_a_x_M_a_s_t_e_r, but one might also, for example,
automatically spool the document for printing.
_H_y_l_a_F_A_X supports a simple form of access control for
receiving facsimile. Each _f_a_x_g_e_t_t_y process may be
configured to check the Transmission Subscriber Identifiers
(TSI) of the remote fax machine against an access control
list, typically eeeettttcccc////ttttssssiiii. Only if the TSI is matched by a
regular expression pattern in the file, is the remote
machine permitted to transmit a document. This mechanism
can be used, for example, to guard against _j_u_n_k _f_a_x.
_H_y_l_a_F_A_X can be configured to do _c_o_p_y _q_u_a_l_i_t_y _c_h_e_c_k_i_n_g on
received facsimile data. When this feature is enabled
_f_a_x_g_e_t_t_y decodes and analyzes the received facsimile data as
it is received. If data is received with too many errors,
according to the setting of the MMMMaaaaxxxxCCCCoooonnnnsssseeeeccccuuuuttttiiiivvvveeeeBBBBaaaaddddLLLLiiiinnnneeeessss and
PPPPeeeerrrrcccceeeennnnttttGGGGooooooooddddLLLLiiiinnnneeeessss configuration parameters, then the sender
will be told to retransmit the page. When copy quality
checking is enabled it is also possible to force received
facsimile data to be saved with a different compression
scheme than was used for transmission. This function is
Page 4 (printed 3/21/00)
HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((JJJJaaaannnnuuuuaaaarrrryyyy 11118888,,,, 1111999999996666)))) HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF))))
known as _t_r_a_n_s_c_o_d_i_n_g and can significantly reduce the space
needed to store received facsimile.
PPPPOOOOLLLLLLLLIIIINNNNGGGG
_H_y_l_a_F_A_X supports the polled retrieval of facsimile
documents. Documents that are received because of a poll
request are stored in the rrrreeeeccccvvvvqqqq subdirectory and also
delivered directly to the requester using the bbbbiiiinnnn////ppppoooollllllllrrrrccccvvvvdddd
command; though the exact command to invoke can be specified
with the PPPPoooollllllllRRRRccccvvvvddddCCCCmmmmdddd configuration parameter. The ppppoooollllllllrrrrccccvvvvdddd
script typically encodes the binary facsimile data and
returns it to the user via electronic mail.
IIIINNNNBBBBOOOOUUUUNNNNDDDD CCCCAAAALLLLLLLL HHHHAAAANNNNDDDDLLLLIIIINNNNGGGG
In environments where Caller-ID information is available,
_H_y_l_a_F_A_X also supports a call screening facility similar to
the TSI access control facility. _f_a_x_g_e_t_t_y can be configured
to check the phone number of each caller against an access
control list, typically eeeettttcccc////cccciiiidddd. Only if the number is
matched by a regular expression pattern in the file is the
call answered. All Caller ID information is logged,
irregardless of whether or not it is used to screen incoming
calls.
_f_a_x_g_e_t_t_y is also capable of using _d_i_s_t_i_n_c_t_i_v_e _r_i_n_g
information to identify whether an inbound call is voice,
data, or fax. Consult the RRRRiiiinnnnggggDDDDaaaattttaaaa, RRRRiiiinnnnggggFFFFaaaaxxxx, and RRRRiiiinnnnggggVVVVooooiiiicccceeee
parameters in _c_o_n_f_i_g(4F) for a description of this facility.
DDDDAAAATTTTAAAA CCCCAAAALLLLLLLLSSSS
Most fax modems also support non-facsimile communication.
_H_y_l_a_F_A_X uses the locking mechanism employed by _u_u_c_p(1C),
_c_u(1C), _s_l_i_p(1M), and _p_p_p(1M). Any _f_a_x_g_e_t_t_y processes will
transparently ``get out of the way'' when an application
wants to use a modem for an outgoing call. In addition,
_H_y_l_a_F_A_X can be configured to deduce whether an incoming call
is for facsimile or data use. If a call from a data modem
is recognized and the GGGGeeeettttttttyyyyAAAArrrrggggssss parameter is specified in
the configuration file, _f_a_x_g_e_t_t_y will invoke the _g_e_t_t_y(1M)
program so that caller may login to the system. Similar
functionality is also available for invoking a ``voice
getty'' process, though auto-detection of inbound voice
calls is less extensive.
SSSSTTTTAAAATTTTUUUUSSSS
_H_y_l_a_F_A_X maintains status information in several forms.
General status information for each server process is
maintained in the ssssttttaaaattttuuuussss subdirectory and returned to users
by the _f_a_x_s_t_a_t(1) program. The _s_y_s_l_o_g(3) facility is used
by all server processed for logging status and error
diagnostics. The server processes may also be configured to
log various kinds of debugging and tracing information; c.f.
Page 5 (printed 3/21/00)
HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((JJJJaaaannnnuuuuaaaarrrryyyy 11118888,,,, 1111999999996666)))) HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF))))
the SSSSeeeerrrrvvvveeeerrrrTTTTrrrraaaacccciiiinnnngggg parameter description in _c_o_n_f_i_g(4F).
Any problems encountered when transmitting a facsimile are
described in messages returned to the user by electronic
mail. A user may also request notification by mail when a
job is requeued; for example, because a call failed.
Notification by electronic mail is implemented by the
bbbbiiiinnnn////nnnnoooottttiiiiffffyyyy command script; though the name of the script may
be overridden with the NNNNoooottttiiiiffffyyyyCCCCmmmmdddd configuration parameter.
The _f_a_x_s_t_a_t utility provides (remote) status of jobs queued
for transmission, jobs received, and the general status of
server processes.
The file eeeettttcccc////xxxxffffeeeerrrrlllloooogggg contains status information about all
facsimile sent and received on a machine. This file is in a
simple ASCII format that is easy to manipulate with programs
such as _a_w_k(1), to generate accounting information. See
_x_f_e_r_l_o_g(4F) for information about the format. See
_x_f_e_r_s_t_a_t_s(1M) and _r_e_c_v_s_t_a_t_s(1M) for example scripts that
print summarized accounting information.
Finally, the _h_f_a_x_d process supports a event monitoring
facility that can be access via the _f_a_x_w_a_t_c_h(1M) program.
This facility permits clients to register interest in
various events and receive ``realtime notification'' when
such events occur on the server. Using this facility it
is/should-be simple to construct applications that do things
like monitor modem status and use.
MMMMOOOODDDDEEEEMMMM SSSSTTTTAAAATTTTEEEE CCCCHHHHAAAANNNNGGGGEEEESSSS
In normal operation each modem is managed by a _H_y_l_a_F_A_X
server process such as _f_a_x_g_e_t_t_y. These processes
communicate with the central scheduler process to notify it
when a modem is ready for use, busy for outbound use, or
possibly in an unusable state (either purposely marked
unavailable or potentially found to be wedged). Modem usage
can be explicitly controlled with the _f_a_x_s_t_a_t_e(1M) program.
The _f_a_x_c_o_n_f_i_g(1M) program can also be used to dynamically
make changes to configuration parameters that may cause a
modem to be treated differently (e.g. setting
RRRRiiiinnnnggggssssBBBBeeeeffffoooorrrreeeeAAAAnnnnsssswwwweeeerrrr to zero will cause _f_a_x_g_e_t_t_y to not answer
incoming calls).
When _H_y_l_a_F_A_X is used in a send-only configuration there are
no _f_a_x_g_e_t_t_y processes and communication must be done
directly with the _f_a_x_q process. The _f_a_x_s_t_a_t_e program can
still be used to manipulate modem use for outbound jobs but
the _f_a_x_c_o_n_f_i_g program is not frequently needed.
JJJJOOOOBBBB SSSSCCCCHHHHEEEEDDDDUUUULLLLIIIINNNNGGGG
Outbound jobs are scheduled by a single process. Jobs have
Page 6 (printed 3/21/00)
HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((JJJJaaaannnnuuuuaaaarrrryyyy 11118888,,,, 1111999999996666)))) HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF))))
a ``scheduling priority'' that is assigned at the time the
job is submitted. This priority can be changed at any time
the job is not actively being processed using the
_f_a_x_a_l_t_e_r(1M) program. A job's scheduling priority may also
be raised by _f_a_x_q in response to certain scheduling events
(e.g. after a failed attempt to send the priority may be
raised).
Modems are assigned to outbound jobs if they are deemed
ready for use. Modem readiness is usually communicated to
_f_a_x_q by per-modem _f_a_x_g_e_t_t_y processes. In a send-only
environment however this is not possible; instead modems
configured for use with _f_a_x_m_o_d_e_m are considered always ready
for use unless they are presently assigned to an outbound
job or their state is explicitly changed through the
_f_a_x_s_t_a_t_e(1M) program (_f_a_x_s_t_a_t_e can also be used in a send-
recv environment).
Each modem has a ``modem priority'' in the range [0..255].
Modems with a lower priority number are assigned to outbound
jobs first. Modem priority is statically configured through
configuration files, the _f_a_x_m_o_d_e_m program, and the _f_a_x_c_o_n_f_i_g
program.
JJJJOOOOBBBB MMMMAAAANNNNAAAAGGGGEEEEMMMMEEEENNNNTTTT
Outbound jobs are considered to be in one of several states
that reflect their treatment by the central scheduling
process. Jobs are initially created in a _s_u_s_p_e_n_d_e_d state,
and may be returned to this state at any time that they are
not actively being processed (e.g. a _f_a_x_s_e_n_d program is
running to process the job). Jobs that are suspended are
not processed by the scheduler; and their internal state may
be safely altered by the owner or a system administrator.
Jobs that are ready for processing by the scheduler are
``submitted'' and their state is changed to be either
_p_e_n_d_i_n_g (delayed waiting for a future time to send),
_s_l_e_e_p_i_n_g (delayed waiting for a scheduled timeout), _b_l_o_c_k_e_d
(delayed by concurrent activity to the same destination), or
_r_e_a_d_y (ready for transmission, waiting only for available
resources). When a job is actively processed by the _f_a_x_s_e_n_d
program its state is marked _a_c_t_i_v_e. Jobs that have
completed, either successfully or unsuccessfully are placed
in a _d_o_n_e state and their job description files are moved to
the ddddoooonnnneeeeqqqq subdirectory. Clients may still access the state
of jobs that are done; until a ``cleaner process'' either
purges them from the system or archives their state. This
delayed removal of a completed job's state permits clients
to resubmit failed jobs using previously transmitted
documents and other job state information. The exact
mechanics of how and when done jobs are processed is
system-dependent; for example, how long a job is left in the
done queue before being purged, and whether job archival
Page 7 (printed 3/21/00)
HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((JJJJaaaannnnuuuuaaaarrrryyyy 11118888,,,, 1111999999996666)))) HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF))))
support is present.
CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN
_H_y_l_a_F_A_X server programs read configuration information from
a configuration file. Multiple files are used, one for the
_f_a_x_q program and one for each modem. Long-running server
programs all automatically re-read their configuration file
if it is modified. Typically this re-reading is done
frequently enough that administrators do not need to be
aware of exactly when it takes place. However in some
esoteric cases the file may not be read when expected (the
one important case is that the _f_a_x_g_e_t_t_y process reads its
configuration file only when answering a call or when
resetting a modem; this means that it will not recognize
changes when the modem is idle).
In addition to the static configuration files, _H_y_l_a_F_A_X
server programs accept commands on their FIFO special files
to alter configuration parameters in the running executable
(the _f_a_x_c_o_n_f_i_g(1M) program can be used to dynamically change
configuration parameters). Values set in this way however
are lost when the process exits or if the configuration file
is re-read.
NNNNOOOOTTTTEEEESSSS
Automatic routing of incoming facsimile is desirable.
FFFFIIIILLLLEEEESSSS
FIFO fifo for job submission
FIFO.<devid> fifo for communicating with a faxgetty process
/usr/freeware/sbin/faxinfocommand that prints information about received facsimile
/usr/freeware/sbin/faxquitcommand to force server to quit
bin/faxrcvd faxd command for handling newly received facsimile
bin/mkcover faxd command for generating continuation cover pages
bin/notify faxd command for doing user notification
bin/pollrcvd faxd command for delivering facsimile received by poll
bin/ps2fax faxd command for converting POSTSCRIPT to TIFF
docq/doc* documents available for transmission
etc/setup.cache server setup file created by _f_a_x_s_e_t_u_p
etc/cid caller id access control list
etc/config.<devid> configuration data for <devid>
etc/hosts hosts that may submit jobs for transmission
etc/tsi fax machine receive access control list
etc/xferlog log of facsimile sent and received
info/* data base of remote fax machine capabilities
client/* FIFO special files created by client processes
config/* prototype configuration files used by _f_a_x_a_d_d_m_o_d_e_m
log/* session logging records
recvq/fax* received facsimile
sendq/q* descriptions of jobs queued for transmission
doneq/q* descriptions of jobs that are done
status/* server status information
Page 8 (printed 3/21/00)
HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((JJJJaaaannnnuuuuaaaarrrryyyy 11118888,,,, 1111999999996666)))) HHHHYYYYLLLLAAAAFFFFAAAAXXXX((((4444FFFF))))
tmp/* temporary files created when submitting a job
archive/* database of archived jobs
SSSSEEEEEEEE AAAALLLLSSSSOOOO
_f_a_x_s_e_t_u_p(1M), _f_a_x_q(1M), _f_a_x_g_e_t_t_y(1M), _h_f_a_x_d(1M),
_f_a_x_s_e_n_d(1M), _f_a_x_r_c_v_d(1M), _f_a_x_c_o_n_f_i_g(1M), _f_a_x_m_o_d_e_m(1M),
_f_a_x_s_t_a_t_e(1M), _n_o_t_i_f_y(1M), _p_o_l_l_r_c_v_d(1M), _r_e_c_v_s_t_a_t_s(1M),
_x_f_e_r_s_t_a_t_s(1M), _a_r_c_h_i_v_e(4F), _c_o_n_f_i_g(4F), _d_i_a_l_r_u_l_e_s(4F),
_d_o_n_e_q(4F), _h_o_s_t_s(4F), _i_n_f_o(4F), _l_o_g(4F), _t_s_i(4F), _r_e_c_v_q(4F),
_s_e_n_d_q(4F), _s_t_a_t_u_s(4F), _x_f_e_r_l_o_g(4F),
Extensive documentation is available in online at
http://www.vix.com/hylafax/. Many of these materials are
also included in the software distribution.
Page 9 (printed 3/21/00)